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1  Introduction 

The  ability  to  view  strike  plans,  such  as  routes  for  airc:raft,  radar  detciction  envelopes  and  terrain  is 
important  to  strike  planners.  A  3D  view  of  the  scenario  provides  the  planmn’  with  an  understanding 
of  the  important  interactions  and  spatial  relationships  between  the  objects  in  the  cmvironnumt. 
Although  current  strike  mission  planning/  visualization  systems  provide  an  acc;eptable  interface  for 
viewing  certain  aspects  of  the  strike  environment,  there  are  two  areas  that  still  need  addressing  in 
order  to  enhance  mission  planning  and  previewing.  The  first  is  the  lack  of  a  true  3D  representation 
of  the  scenario.  Current  systems  do  work  with  3D  information  such  as  terrain,  routes,  etc:.  However, 
this  3D  information  is  disi)layed  on  a  monitor  that  is  2D  in  nature.  What  is  needed  is  a  better 
approach  to  visualizing  the  important  spatial  relationships  on  a  2D  monitor.  The  sec:ond  item 
which  is  deficient  is  a  poor  visual  representation  of  Radar  Terrain  Masking  (RTM).  The  problem  of 
representing  RTM  is  of  great  importance  to  strike  planners.  When  terrain  obscures  the  view  of  a 
radar  in  a  certain  direction,  we  say  that  the  terrain  has  masked  the  view  of  the  radar.  The  ability 
to  accuratcdy  identify  RTM  gives  the  planner  a  visual  representation  of  where  the  “holc!s”  are  in 
the  radars  coverage.  These  “holes”  represent  safe  areas  through  which  strike  aircraft  may  avoid 
detection.  Additionally,  if  the  strike  jrlanner  has  to  modify  the  routes,  then  the  ability  to  visualize 
RTM  is  vc;ry  important. 

NRL  has  developed  a  Decision  Support  System  (DSS),  hereafter  referred  to  as  the  STrike  Optimized 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 
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Mission  Planning  Modulo,  or  STOMPM  [3].  This  decision  aid  serves  as  a  testbed  for  research  and 
devcdopineiit  of  asset  routing  algorithms,  where  the  assets  may  be  strike  aircraft  or  missiles.  Th(!S(! 
routing  algorithms  take  into  consideration  the  positions  of  eiKuiiy  radars,  intemkid  targets,  and  tlu; 
features  of  the  terrain.  We  have  investigated  various  tcjchnicpies  within  this  DSS  whicdi  c.ould  improv(> 
current  strike  planning/visualization  systems,  particularly  with  regard  to  more  realistic  3D  disjjlays 
and  a  better  visual  model  for  RTM. 

With  regard  to  better  3D  displays,  we  have  incorporated  stereo  graphics  within  the  STOMPM 
interface.  This  stereo  interface  is  further  enhanced  by  the  use  of  a  virtual  workbench.  The  virtual 
workbench  consists  of  a  translucent  table  top  containing  a  mirror  placed  at  a  45  degree  angle  beneath 
the  table  top.  Vickio  is  ])rojected  onto  the  mirror,  which  reflects  the  image  onto  the  transluctuit  table 
top.  Since  this  vidcio  contains  3D  stereo  information,  the  images  (xmtaiiKKl  in  tin;  video  ai)i)(!ar  as 
floating  above/below  the  table  top.  This  approach  has  led  to  a  more  nialistic  disjday  of  tlui  strike 
enviromiHuit.  With  regard  to  RTM,  we  have  developed  a  line-of-sight  radar  niockd.  In  this  mockd, 
a  cone,  with  its  vertex  placed  at  the  location  of  a  radar,  sweeps  continuously  in  animated  secpicmcx; 
from  minimum  to  maximum  elevation.  RTM  effects  are  easily  visualized  using  this  model,  dne  to 
the  fact  that  the  j^ortions  of  the  cone  blocked  by  the  terrain  at  each  elevation  angki,  are  removed 
from  the  cone  itself.  This  provides  a  strong  visual  cue  as  to  what  is  visible  to  the  radar  at  (!ach 
elevation  angle  and  direction. 

Section  2  will  cover  the  3D  line-of-sight  model  for  R,TM,  and  discuss  its  advantages  over  cnirrent 
methods  for  visualizing  RTM.  Section  3  will  descnibe  the  stereoscopic  interface;  that  has  Ixien  inipk;- 
mented  on  the  virtual  workbench  within  the  DSS  to  enhance  the  visual  caj)abilities  of  the;  system. 
We  will  also  detail  some  of  the  limitations  associated  with  the  use  of  stereo.  A  bri<;f  summary,  with 
conclusions,  is  preisented  in  section  4. 

2  Visualizing  RTM  Effectively  in  3D 

In  the;  strike  ai)i)lication,  the  deficiencies  with  common  methods  for  visualizing  radar  detection 
regions  were  already  well  known.  The  most  common  representation  of  detection  regions  is  as  hemi¬ 
spherical  domes  dehned  by  the  maximum  range  of  the  radar  (similar  to  Figure  1,  but  with  non¬ 
transparent  domes).  These  domes  have  portions  cut  out  due  to  terrain  masking  of  the  radar,  but 
these  cut  regions  are  usually  occluded  by  non-masked  regions.  In  other  words,  the  most  imjjortant 
features  the  masked  regions  dehning  safe  corridors  for  strike  aircraft  -  cannot  easily  be  seen.  Using 
semi-transparent  (fog/haze)  graphical  representations  are  often  used  so  that  the  masked  regions  can 
be  at  least  partially  seen  through  the  detection  regions.  In  practice,  unfortunately,  the  result  is  less 
than  satisfactory  (see  figure  1). 

Moving  to  a  3D  display  seems  to  be  a  good  solution  to  the  RTM  problem  because  it  promises  to 
allow  the  user  to  cpiickly  hnd  a  point-of-view  from  which  the  various  maskc'd  r(;gions  c.an  b(!  (iasily 


soon  and  stndiod.  Experiments  with  detection  domes  reveal,  however,  that  while  the  masked  regions 
can  be  scuui  well  from  various  angles,  it  is  still  not  ])ossil)le  to  study  the  regions  from  the  diref:tion 
of  a  ])ro])osed  strike  route  because  they  are  usually  occluded  by  noii-masked  parts.  What  is  needed 
is  a  way  to  strip  away  the  occluding  i)ortions  so  that  the  masked  region  along  tlw;  route;  can  be;  seem 
clearly.  Sophisticated  interaction  techniques  using  sensor  gloves  might  provide  an  interface;  feu-  the 
user  to  manipulate  the  portions  of  the  dome  that  are  elisplayeel  (or  not  displayed),  but  this  we)ulel 
probably  result  in  a  tedious  exercise  for  the  eiser  to  retain  precisely  the  desired  regions  of  interest. 
A  faster  and  more  fle;xibie  visualization  tool  is  needed. 

Recognizing  that  the  user  needs  to  see  different  slices  of  the  detection  dome  independently  in  order 
to  make  sense  of  the  complicated  interactions  between  terrain  and  the  radar’s  region  of  coverage, 
souk;  nic;thod  is  ne(;ded  to  generate  and  display  the  relevant  slices  of  the  dome;  automatically.  It 
is  of  course  impossible  to  i)roduce  a  general  purpose  strategy  for  identifying  what  slic(;s  arc;  “most 
relevant”  to  a  sjmcific  api)lication,  so  some  unint(;lligent  strategy  is  reciuired.  The  most  li(;xibl(; 
approach  along  th(;se  lines  is  to  use  the  fourth  dimension,  time,  to  iteratively  cycle;  over  some  fix(;d 
decomposition  of  the  radar  dome.  One  could,  for  exanij)le,  iteratively  display  different  i^lanar  slic.es 
of  the  dome,  one  after  another.  This  type  of  display  jjroduces  a  succession  of  flat  surfac(;s.  This  way 
of  decomposing  the  dome,  however,  does  not  seem  particularly  useful  because  the  planar  slic;es  do 
not  have  any  physical  relevance  to  the  geometry  involved  in  RTM. 

The  geometry  of  a  line-of-sight  radar  inherently  defines  a  polar  coordinate  system  with  its  origin  at 
the  position  of  the  radar.  In  suc.h  a  polar  coordinate  frame  the  important  dimensions  are  range,  az¬ 
imuth,  and  elevation.  By  displaying  two  of  the  dini(;nsions  and  iterating  over  the  third,  an  animated 
disj^lay  can  be  generated  that  (a)  allows  the;  user  to  see  different  portions  of  the  rc;gion  in  isola¬ 
tion  and  (b)  gives  the  user  intuition  about  the  overall  3D  structures  of  the  detection  regions.  The 
(piestion  that  must  be  answered  is  which,  if  any,  of  the  choices  of  coordinates  to  animate;  provid(;s 
adequate;  visualization  of  the  masked  regions. 

Iterating  on  range;  yields  an  animated  sequence  in  which  the  detection  region  starts  as  a  point 
and  then  exi)ands  to  the  full  radar  dome  (figure  1).  Unfortunately,  this  display  provides  little 
information  beyond  what  is  provided  by  the  full  radar  dome  alone.  Iterating  on  azimuth  produc,e;s 
a  wedge  define;d  by  the  minimum  and  maximum  e;levation  and  detection  range  of  the  sensor  at  each 
discretized  azimuth  value  (Figure  2).  The  wedge  sweejis  around  the  sensor  and  clearly  traces  over 
the  terrain  masked  regions.  One  of  the  principal  features  of  the  wedge  disphiy  is  that  wh(;n  c,ombin(;d 
with  a  static;  plot  of  a  proposed  strike  route,  a  viewer  can  see  as  the  w(;dge  swc;(;ps  p{;rpendicular 
to  a  leg  of  the  route;  and  determine  whether  the  route;  goes  through  a  maske;d  re;gion  or  is  within 
the  elete;e;tion  region  of  the  radar.  The  only  elrawbae;k  of  the  the  wedge  disphiy  is  that  it  does  not 
jirovide  the  vi(;wer  with  a  strong  sense  of  the  3D  extents  of  the  masked  regions. 


Figure  1  (left):  Semi-Transparent  Radar  Dome;  Figure  2  (right):  Wedge 

Implementation  of  RTM 

Iterating  on  elevation  generates  a  cone  that  continuously  sweeps  from  minimum  to  maximum  to 
minimum  elevation  (Figures  4-6).  This  cone  appears  to  melt  over  the  terrain  as  it  sweei)s  down 
from  maximum  elevation  onto  the  terrain  features  and,  in  so  doing,  gives  a  strong  sense  of  where 
the  masking  effects  are  most  pronounced.  In  strike  applications,  the  cone  display  provides  an  ideal 
visualization  tool  for  determining  when  a  proposed  route  is  within  the  detection  region  of  the  radar. 
Specifically,  by  watching  as  the  cone  sweej)s  up  and  down  it  is  possible  to  see  exactly  where  and  how 
it  intersects  a  static  plot  of  the  route. 

In  STimmary,  by  displaying  individual  slices  of  a  radar  detection  dome  in  isolation,  the  viewer  is 
able  to  discern  critical  information  that  would  otherwise  be  occluded  if  all  of  the  radar  detection 
information  were  displayed  at  once.  FurthernKwe,,  by  animating  a  scxpiencc!  of  slices  the  viewer  is 
able  to  mentally  constiuict  a  complete  picture  of  the  3D  structure  of  the  radar  dome  while  at  the 
same  time  is  able  to  scrutinize  individual  slices  in  the;  animated  sequence.  There  does  not  a])i)ear  to 
be  any  conij)arably  effective  visualization  strategy  that  will  work  on  a  2D  displa.y. 

3  Stereoscopic  visualization  on  the  Virtual  Workbench 

Once  strike  plans  have  been  generated  for  a  given  scenario,  displaying  the  plans  and  the  scenario  itself 
in  a  form  in  which  the  important  spatial  relationships  are  easily  seen  has  been  an  important  issue  in 
strike  visualization.  In  some  instances,  one  can  get  sufficient  knowledge  of  the  scene  by  viewing  3D 
information  without  the  use  of  stereo.  However,  extracting  detailed  information  and  relationshi])s 
in  the  data  sometimes  is  made  easier  by  the  use  of  stereo.  Consider  the  simple  case;  of  viewing  the 
scenario  (consisting  of  radar  cones,  tcirrain,  and  aircraft  routes)  from  an  orthogonal  vitiwing  i)osition 
on  the  computer  monitor  '.  It  may  be  difficult  to  precisely  obtain  altitude  information  because 
altitude;  is  in  the  same  direction  as  a  vector  i)erpendic;ular  to  the  comj)uter  scr(!en,  and  h(!nc<!  there 


M)y  “ortliogonal  viewing  position”,  we  mean  an  eye  position  wliich  is  looking  in  the  -z  direction  onto  the  scenario. 


are  no  deptli  encis  for  the  viewer.  This  situation  is  alleviated  when  the  same  sc'ene  is  vi(!W(Hl  in 
ster(X).  Th(!  nse  of  stereo  makes  visualizing  depth  easier.  In  fact,  the  use;  of  sterex)  allows  the  user  to 
view  details  of  the  strike  environment  from  a  relatively  orthogonal  viewing  position,  without  having 
to  set  the  viewpoint  to  some  other  perspective. 

The  advantage  of  the  use  of  stereo  on  the  virtual  workbench  is  chxir.  Viewing  the  scenario  from 
an  orthogonal  eye  jjosition  gives  the  most  overall  information  because  very  little  is  hidden  to  the 
viewer,  whereas  in  some  other  projection,  the  effects  of  z-biiffering  [4]  may  hide  important  jjarts  of 
the  terrain,  routes,  etc.  This  is  one  of  the  reasons  orthogonally  projected  views  are  used  extensively 
in  mission  planning  systems.  However,  the  orthogonal  viewing  position  has  limitations  in  non-stereo 
mode.  Stereo  allows  one  to  visualize  details  of  the  terrain  and  routes  from  an  ortliogonal  viciwing 
position,  not  having  to  view  the  terrain/routes  with  respect  to  the  horizon  to  obtain  important 
visual  information. 

We  have  modified  the  STOMPM  interface  to  incorporate  stereo  graphics  [1]  [2].  Stereo  graphics 
works  in  the  following  way:  i)roduce  two  images  of  the  scene,  one  in  the  toj)  half  of  the  display 
and  one  in  the  bottom  half  of  the  display.  When  the  monitor’s  refresh  rate  is  doubled  to  12()HZ, 
only  half  of  the  60HZ  display  is  used  for  each  refresh.  One  of  these  images  is  for  the  right  eye  (the 
one  that  was  drawn  to  the  bottom  of  the  display)  and  one  for  the  left  (the  one  tliat  was  drawm  to 
the  top  of  the  display).  The  user  can  then  wear  Liepiid  Crystal  Display  (LCD)  shutter  glasses  to 
view  the  image  in  stereo.  The  shutter  glasses  work  by  showing  the  left  eye  the  image  intended  for 
the  left  eye  at  the  6()HZ  refresh  rate,  similarly  for  the  right  eye.  However,  each  eye  sees  the  image 
meant  for  it  in  alternating  sequence.  The  shutters  in  the  glasses  open  and  close  in  synchronization 
with  the  monitors  refresh  rate  (the  synchronization  signal  is  sent  to  the  glasses  from  an  emitter). 
The  overall  effect  to  the  user  is  a  view  which  more  closely  resembles  3D  the  stereo  image  can  lx; 
either  projected  in  front  of,  or  behind,  the  (X)mputer  screen,  by  adjusting  a  certain  parani(;ter  in  the 
software. 

Now  the  (}uestion  arises  whether  to  view  the  orthogonally  displayed  image  (mentioned  in  the  second 
paragraph  of  this  section)  on  the  computer  monitor  or  the  workbench?  It  may  appear  that  oix;  is 
just  as  appropriate  as  the  other.  However,  the  ability  to  interact  with  the  scenario  (i.e.,  clicking 
near  entities  to  get  information  about  them,  repositioning  entities,  modifying  routes,  etc)  is  most 
easily  accomplished  when  it  is  displayed  on  a  table  top  environment,  such  as  the  workbench.  This  is 
because  usc;rs  naturally  i)erceive  altitude  in  the  same  direction  as  a  vector  which  is  perpendicular  to 
the  (;arth.  On  a  cxjinputer  monitor,  altitude  would  be  in  the  same  direction  as  a  vector  peri)endic,nlar 
to  the  compute;!-  screen.  This  is  a  little;  awkwarel  to  work  with,  especially  when  trying  to  aeljust  the; 
re)utes  in  the;  z  direction. 

We  have;  e;nhanc:eel  the  stereo  interface  further  by  displaying  this  stereo  image  on  a  virtual  we)rkbe;ne:h. 
The  workbenc.h  was  developed  by  the  Virtual  Re;ality  (VR)  group  of  the  Aelvanc;e;d  Information 


Technology  (AIT)  branch  at  NRL.  The  schematic  for  the  virtual  workbench  can  be  seen  in  Fignre 
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Figure  3:  Schematic  diagram  of  Virtual  Workbench. 

Video  from  tlie  computer  is  sent  to  the  projector,  which  projects  the  image  onto  a  mirror.  The  mirror 
reflects  this  image  onto  a  translucent  table  top.  Two  pairs  of  emitters  are  placed  at  the  back  two 
corners  of  the  table  top.  The  use  of  two  pairs  of  emitters  provides  a  stronger  synchronization  signal 
for  tlie  sliutter  glasses.  Wlien  displaying  an  image  on  the  workbench,  tlie  user  can  control  wlietlier 
tlie  image!  ajjpears  to  float  al)ove,  or  just  iielow,  tlie  table  toji.  Tliis  is  controllcid  iiy  adjusting  a 
certain  parameter  in  tlie  software  (just  as  tlie  image  was  made  to  projec.t  as  eitlier  inside  or  outside 
tlie  cominiter  screen). 

We  are  also  working  to  develop  tecliniciues  for  interacting  witli  tlie  scene  on  tlie  workliencli.  Tlie 
AIT  VR  group  lias  integrated  a  sensor  glove  within  tlie  workbencli  environment.  Tlie  user  wears  tliis 
glove  wlien  interacting  witli  the  environment  on  tlie  workbencii.  Ry  tondiing  two  fingers  togetlier 
wearing  the  glove,  an  EVENT  is  registered.  Tlie  apjilication  program  can  then  use  tliis  event  to 
manipulate  tlie  scene  in  some  fashion.  Tliis  sensor  glove  technology  can  be  used,  for  example,  to  click 
near  a  radar,  routes,  or  targets  to  get  specific  information  about  tliem.  Tiie  ability  to  manipulate 
the  scene  is  also  important  (i.e.,  adjusting  tlie  routes,  clianging  the  position  of  radars  and  targets, 
etc).  Again,  tlu!  sensor  glove  can  lie  used  in  a  very  natural  way  to  move  and  edit  olijects  in  the 
scenario  region. 

One  (piestion  that  will  need  to  be  addressed  is  liow  to  liest  disiilay,  on  the  worklKincli,  textual 
attriiiutes  such  as  positions  of  radars,  targets,  ranges  of  radars,  etc,  wlien  tlie  user  dicks  near  tiieni. 
Experimentation  witli  various  types  of  tedmiciues,  (siicli  as  wlietlier  to  display  “freii”  text  at  tlie 


point  wh(!r(;  tlio  user  touches  the  sensor  glove;  fingers  together,  or  to  show  this  t,(!xt  on  some  tyjx; 
of  “status”  board  at  some  location  on  the  workbench)  will  have  to  be  done  to  determine  the  best 
interface  for  textual  information.  In  any  ai)proach  that  is  taken,  the  text,  or  any  “status”  board 
containing  text,  will  have  to  be  drawn  as  part  of  the  scene  in  stereo  as  well.  Oik;  cannot  just  open  up 
a  separate  display  window  for  textual  information  because  the  window  will  not  be  proj(!cted  either 
on  top  of  or  underneath  the  table  top  (it  will  appear  to  lie  at  the  interface  and  can  disturb  the  stercio 
effect). 

There  are  several  items  worth  mentioning  about  the  use  of  stereo.  As  was  already  mentioned,  the 
stereo  image  can  be  made  to  float  above  or  just  below  the  virtual  workbench  table  top,  by  adjusting 
a  certain  parameter  in  the  software.  When  one  sets  the  parameter  such  that  the  image  is  floating 
above  the  table  top,  the  interaction  of  the  stereo  image  with  the  clipping  jdanes  determines  how  wcdl 
the  st(!reo  effect  is  preserved.  Zooming  or  i)anning  effects  can  disturb  the  stereo  effect  txicausc;  this 
can  canse  tlx;  stereo  image  to  be  clipped  by  the  clipping  planes.  This  is  an  artifact  of  stercio,  and 
does  not  deptuid  on  whether  the  stereo  image  is  projected  on  the  computer  screen  or  the  workbench. 
It  is  important  to  have  the  entire  scene  visible  when  one  wishes  to  ])roject  the  image  outside  of 
the  computer  screen,  or  on  top  of  the  workbench.  However,  by  having  the  entire  scene  visible  on 
the  workbench  (or  computer  screen),  it  may  be  impossible  to  view  the  important  details  associated 
with  the  scenario.  In  many  instances,  it  is  desirable  to  project  the  image  underneath  the  table  top, 
or  inside  the  computer  screen.  What  we’ve  noticed  is  that  in  our  particular  application,  when  t.he 
maximum  height  of  the  viewable  terrain  is  underneath  the  table  top  (even  after  panning  or  zooming) , 
the  clipping  planes  have  no  adverse  effect  on  the  stereo  image.  In  this  regard,  it  may  lx;  easier  to 
zoom  or  pan,  thns  enabling  more  details  associated  with  the  scenario  to  be  seen. 

3.1  Examples 

The  sc(!narios  in  Figures  4-6  are  placed  at  the  Naval  Air  Station  (NAS)  Fallon  t,(!St;  range  locatcxl 
near  Fallon,  Nevada.  It  shonld  be  mentioned  that  only  the  Digital  Terrain  Ehwatlon  Data  (DTED), 
overlayed  with  Landsat  imagery  is  used  to  represent  the  strike  environment  these;  are  not  actual 
strike  sc(;narios.  The  scenarios  consist  of  cones  (r(;presenting  the  radars’  360  degr(;e  vi(;w)  sw(;eping 
from  their  minimum  to  maximum  detection  elevations.  Areas  (;ut  out  from  each  cone  rev(;al  tlx; 
effects  of  terrain  on  the  detection  region  of  the  radar.  These  “terrain  masked”  regions  represent 
holes  through  which  strike  aircraft  may  avoid  detection.  The  animation  of  the  cones  sweeping 
continuously  from  minimum  to  maximum  elevation  of  detection  represents  a  novel  visualization  tool 
for  identifying  holes  in  a  radar’s  coverage.  Figure  7  shows  a  suppression  route  (which  destroys  oix; 
of  tlx;  radar  sites).  This  l(;aves  a  safe  corridor  for  the  attack  aircraft  to  pass  through  in  reaching 
their  desired  targets. 


Figure  4  (left):  Cones  at  minimum  elevation;  Figure  5  (right)  Cones  at  median 
elevation  (both  figures  in  non-stereo  mode.) 


Figure  6  (left):  Cones  at  maximtim  elevation;  Figure  7  (right)  Suppression  and  Attack 

rontes  (both  figures  in  non-stereo  mode.) 


Wo  have  also  built  a  simulation  capability  in  which  the  routes  evolve  over  time  to  their  destinations. 
This  provides  the  user  with  important  information,  such  as  where  the  routes  are  with  resi)ec,t  to 
each  other  at  specified  times.  The  ability  to  simulate  the  routes,  with  the  animation  of  the  cones 
moving  from  minimum,  median,  to  maximum  detection  elevation  in  stereo  on  the  virtual  workbench 
provides  the  user  with  a  detailed  account  of  the  spatial  relationships  in  the  scenario,  particularly 
RTM. 

4  Summary  and  Conclusions 

Current  planning  systems  arc  non-stereo  and  generally  use  displays  that  are  set  to  an  orthogonal 
viewing  position,  but  previewing  is  done  in  either  an  orthogonal,  or  other,  position  (however,  z- 
buffering  effects  may  hide  some  aspects  of  the  scenario  when  the  display  is  not  in  orthogonal  viewing 
mode).  Although  ijlanning  systems  use  orthogonal  viewing  positions,  there  are  certain  limitations 
that  still  api)ly. 


Without  steroo  grai)liics,  3D  planning  has  certain  obvious  limitations.  As  an  example,  consider  the 
case  of  trying  to  adjust  routes  in  3D  space  while  in  orthogonal  viewing  mode.  In  this  mode,  there  an; 
no  depth  cues  to  adjust  by.  In  current  systems,  one  has  to  manually  enter  tlu;  latitude  and  longituchi 
for  the  routes  in  2D  (either  by  clicking  in  the  scenario  region  or  tyj)ing  the  latitude,  longitude! 
values),  but  then  one  has  to  adjust  the  altitude  via  a  sejiarate  window  (adjustment  also  may  include 
moving  any  waypoint  on  the  route  in  any  given  direction).  This  becomes  a  time  consuming  task. 
In  non-orthogonal  viewing  mode,  one  may  be  able  to  adjust  the  routes,  but  if  the  routes  are  hidden 
behind  objects  such  as  terrain,  they  may  not  be  seen  from  a  given  non-orthogonal  mode  and  may 
require  rotations  for  proper  viewing,  etc.  Rotations  are  a  cumbersome  calculation  and  if  the  number 
needed  becomes  prohibitively  large  (which  might  well  occur  if  the  terrain  is  extremely  mountainous, 
the  number  of  planners  is  large,  or  one  has  to  adjust/rotate/adjust/rotate  in  succession),  valuable 
planning  time  may  be  wasted.  Previewing  the  scenario  in  orthogonal  mode  also  does  not  ])rovid(! 
mucdi  in  the  way  of  substantial  depth  cues.  However,  previewing  in  non-orthogonal  mode  may  be 
fine  since  very  little  user  interaction  is  occuring  with  the  scenario  during  previewing.  Generally,  a 
few  good  viewpoints  will  be  enough  to  see  what  is  going  on  in  the  scenario,  tlmreforc!  rciducing  the; 
cost  of  rotations. 

With  the  use  of  stereo  on  the  workbench  (in  addition  to  the  use  of  a  sensor  glove  for  interaction 
purposes),  one  can  effectively  plan  and  preview  while  the  system  is  in  orthogonal  viewing  mode 
(moreso  than  if  the  stereo  image  were  projected  on  a  computer  screen),  thus  reducing  the  cumbersome 
calculations  needed  for  scene  rotations  in  non-orthogonal  viewing  mode.  If  the  planner  insists  on 
using  non-orthogonal  mode  for  previewing,  in  stereo,  then  certain  conditions  should  be  met  in  order 
for  the  stereo  eff(!ct  to  work  properly.  In  fact,  the  first  two  conditions  should  be  met  whenev(!r  using 
ster(!o: 

1.  th(!  clipi)ing  planes  do  not  adv(!rsely  affect  tlu!  scenario  when  it  is  projected  above  the  table! 
top  or 

2.  the  scene  is  projected  underneath  the  table  top. 

3.  either  I  or  2  being  coupled  with  the  effects  of  z-buffering,  or  cost  of  the  scene  rotations,  being 
tolerated  (applies  also  in  non-stereo  mode). 

Planning  in  non-orthogonal  viewing  mode  in  stereo  may  suffer  the  same  drawbacks  as  in  the  C!as(! 
of  non-stereo  mode  (i.e.,  cost  of  rotations).  It  should  be  clear  that  certain  parts  of  the  planning 
j)rocess  (like  adjusting  the  routes)  are  best  done  quickly  and  efficiently  in  stereo  using  an  orthogonal 
viewing  position  (and  it  should  also  be  dear  why  most  syst(!nis  stay  away  from  non-orthogonal  views 
for  i)laiming).  For  previewing,  the  use  of  a  non-orthogonal  previewing  position  in  non-stereo  mode 
may  be  sufficient,  but  does  not  provide  the  planner  with  the  best  depth  cues  as  obtained  via  stereo. 
The  use  of  a  [non]  orthogonal  viewing  position  coupled  with  stereo  mode  {provides  better  depth  cues 


than  the  non-Ht(ireo,  iion-orthogonal  previewing  jjosition. 


We  have  enhanced  tlie  capability  of  our  system  by  using  steixiographics  on  a  virtual  workbcuich.  This 
method  of  visualization,  along  with  the  line-of-sight  model  for  RTM,  has  greatly  improved  tlu;  ability 
to  plan  and  prtwiew  by  enhancing  the  ability  to  see  the  spatial  relationships  in  a  strike  scenario. 
We  feel  that  this  is  a  better  approach  than  standard  VR  techniques  for  strike  visualization  because 
it  still  allows  multiple  planners  to  interact  with  each  other,  as  they  preview  or  modify  the  scenario 
(because  the  sluitter  glasses  are  transparent).  In  virtual  reality  displays,  the  ability  to  interact  with 
other  planners  would  be  lost  mainly  because  a  head-mounted  display  must  be  worn  by  the  user,  thus 
restricting  his  ability  to  interact  with  the  other  planners. 

The  stercio  interface  coupled  with  the  workluuich  has  also  been  used  for  displaying  and  interacting 
with  visualization  objects  generated  using  the  results  from  a  numerical  simulation  of  an  axially 
excitcxi  free  scpiare  jet  [5],  visualizing  the  airwakc;  and  c?xhaust  gas  trajectiories  over  the;  DDG51 
destroyer  [5]  [6] ,  and  mcxlical  visualization  [7]  It  is  also  being  investigated  for  visualizing  commcu'cial 
aircraft  routes  for  the  Federal  Aviation  Administration  (FA A).  We  feel  that  the',  stcu'cio  interface  or 
stereo  interface  coupled  with  the  workbench  has  the  capability  to  enhance  the  uscu'  interface  of  any 
decision  support  system  (particularly  when  it  comes  to  visualizing  the  spatial  relationships  between 
the  data),  whether  it  be  in  the  military  or  business  enteri)rise. 
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